Missing signatures compared to the public instance

[simone-co]

About accounts on capesandbox.com

• Issues isn't the way to ask for account acctivation. Ping capesandbox in Twitter with your username

This is opensource and you getting free support so be friendly!

• Free support from doomedraven ended, no whiskey no support. For something he updated the documentation :)

Prerequisites

Please answer the following questions for yourself before submitting an issue.

• [x] I am running the latest version
• [x] I did read the README!
• [x] I checked the documentation and found no answer
• [x] I checked to make sure that this issue has not already been filed
• [x] I'm reporting the issue to the correct repository (for multi-repository projects)
• [x] I'm have read all configs with all optional parts
• [x] I'm have checked discussions section

Expected Behavior

I tried to analyze this sample in a new private cape installation. I expected it to show the same signatures.

Current Behavior

Failure Information (for bugs)

I tried to reload the signatures several times through community.py with argument -waf but unfortunately it seems that they are not seen. I tried to change the configuration, reinstall the os and cape several times, but the problem is not solved.

Steps to Reproduce

Analyze one sample in new fresh installation.

Context

I followed the installation and configuration instructions. they seem to be seen also from the web side less signature in the status field than in the public version.

Question	Answer
Git commit	commit ab30a65ef1aa71a068a811b1501c57abe90598ad
OS version	Ubuntu 22.04.1 LTS

Failure Logs

[doomedraven]

Hello, thats because the detonation is different, maybe is some VM problems that gives you different output or less output. or less time executed in vm

[simone-co]

Hi, thank you for your reply. I am aware that different configurations of the vm can change the behavior but the signature for dynamic load is not triggered either and in the behavior are the api LdrGetProcedureAddress, LdrLoadDll. By checking the rule the signature should be flagged. As you can see in these two analyses on the public instance (of the same file, just check sha256) the signatures change. OLD and NEW

I would like to contribute to the cape project by reporting any bugs I find and proposing new features.

Thank you for your attention.

[doomedraven]

@kevoreilly could it be related to the recent LdrLoadDll that we spoke in PM?

[kevoreilly]

Nah that was specific to SL loading ntdll copy and has monitor workaround.

As I said before signatures are secondary to the behavior log. The process tree is also derived from the behavior log. Look at how they differ for those two jobs!

So the question here is really about massively differing detonations from the same sample. My first guess would be that the first job (297569) has (internet/vpn) route 'Italy' where the latter (297999) has route 'None' so couldn't download further stages, but that's at a glance. My point being this isn't really about signatures.

[doomedraven]

good point

[simone-co]

@kevoreilly New analysis with route on italy has the same behavior as the no route.

OLD

NEW

if we compare the two behaviors with the signature in the old analysis we see that the api chain is about the same.

Checking in the behavior section the signature api dynamic_function_loading.py is present but the signature is not shown. If the api are present shouldn't the signature also be shown? isn't it more likely to be two problems one on the detonation and one on the signature?

P.S. Checking the behavioral log manually, the recent analyses all show the same problem. I can try checking the other signatures manually.

[kevoreilly]

Yes you are right, the presence of the apis in the log should result in the signature firing.

Looks like a slew of signature errors upon reprocessing... So I take it back! There is indeed a signature problem.

[doomedraven]

I will check it after gym

[kevoreilly]

Cheers doomed

[simone-co]

I recommend also verifying that there are no problems in detonation. Checking some analysis, from two days ago, in them show problems with thread follow and some anti-sandbox techniques, some samples do not detonate correctly and do not show all behavior, I investigate the problem and open another issues when I find out more.

To propose new bypasses and signatures, do I have to use issues or is it better to use discussions ?

Thank you for your attention.

[kevoreilly]

Issues is fine - just create a new issue for each sample/family that has detonation problems and ideally share a sample. I spend a lot of my life trying to solve detonation problems but am always grateful to have the information.

[doomedraven]

Open issue as those requieres solution

El jue, 11 ago 2022 18:13, Simone C @.***> escribió:

I recommend also verifying that there are no problems in detonation. Checking some analysis, from two days ago, in them show problems with thread follow and some anti-sandbox techniques, some samples do not detonate correctly and do not show all behavior, I investigate the problem and open another issues when I find out more.

To propose new bypasses and signatures, can issues be used or is it better to open a discussion?

Thank you for your attention.

— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/1072#issuecomment-1212199531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFH3YJ6NEZDMR2SNYTUPDVYURDXANCNFSM56HPQZYQ . You are receiving this because you commented.Message ID: @.***>

[doomedraven]

so signature itself works just fine, but for some reason even forcing it to return True, it not stored to mongo

[doomedraven]

@simone-co you was right, there was bug in recent update. it wasn't matching properly on_complete.do git pull and test it please. it works now if i reprocess samples

[doomedraven]

update community with python3 utils/community.py -waf

[simone-co]

@doomedraven Hi, trying in the public instance would seem to work fine. I will try on a new cape installation shortly.

Thanks.

[simone-co]

@doomedraven In my cape instance the signature problem remains, in the behaviour there are calls to apis but signature not firing.

And it also presents a crash related to extract_overlay_data.

Note that in the public instance the sample detonates only with vpn italy, but not with route italy (no vpn). I'm italian and server is in italy but it no detonate correctly.

The vm I configured is currently invisible to pafish (except for rdtsc vmexit, new pafish version is with sleep).

I am continuing to investigate the problem to provide more information.

Thank you.

[doomedraven]

pafish is dead, use al-khaser for antivm testing ;)

about signature that is strange

[doomedraven]

@TheMythologist does it sound to you the error of the key in process_overlay_file? i see there is self.key

[doomedraven]

@simone-co did you restart cape-processor/process.py after update? did you update community repo too?

[TheMythologist]

@TheMythologist does it sound to you the error of the key in process_overlay_file? i see there is self.key

Yup I should have used dict.get instead (probably because extract_overlay us disabled in config file)

[simone-co]

@simone-co did you restart cape-processor/process.py after update? did you update community repo too?

Yes, I restart all cape's services every time after update and I do the same with community. I'll update cape soon.

[doomedraven]

hm now im not really sure what is wrong, i just tested resubmitting sample instead of reprocess it and it works here. maybe try to add some debug statements in that signature on_complete

[doomedraven]

any update here?

[merfin993]

@doomedraven Hi, I'm luca the colleague of simone.co. I apologize for the delayed reply.

We tried to do some debugging and all signatures seem to be running correctly. (the conditions are executed correctly and also on_complete) But, unfortunately, the signature is not shown yet. Simone and I are continuing to investigate the problem.

Thanks.

[doomedraven]

np, thanks, let us know if you spot what is wrong

[doomedraven]

you can use process.py -r X -sig -sn <signame> to debug uniq sig

[doomedraven]

now i found case where signature is matched but cape says it not matched, investigating

[doomedraven]

i just pushed fix for my case, please do git pull and try again

[merfin993]

ok, we'll test soon

[merfin993]

@doomedraven Hi, the problem is not solved and has also reappeared on the public instance.

we can see it with the analysis. https://capesandbox.com/analysis/311663/

Let's see the overview.

The signature for dynamic loading not firing. (https://github.com/kevoreilly/community/blob/master/modules/signatures/dynamic_function_loading.py)

In behaviour log we see LdrGetProcedureAddress and LdrLoadDll .

We continue to investigate.

Luca.

[doomedraven]

your job, cape not always on latest, depends how much work we have, just pulled all updates and reprocessed and i see it. I also just in case resubmitted it and see it to not reprocess https://capesandbox.com/analysis/311680/

[merfin993]

@doomedraven Yes, the problem now is also solved on our private server, I apologize for assuming that the public instance was updated, sorry.

Luca.

[doomedraven]

glad that is solved, so yes the bug that i found last week was somehow related, not sure how it was working before with that bug %). let me know if you find any other problem. closing this one