Hello, I am totally new here. I wanted to work on this issue. Can you please give more insights?

Welcome! For dynamic analysis we should look into "file limitations" like e.g. .NET samples.

The first step here would be to identify a .NET sample from the sandbox files (for VMRay and CAPE first), example files can be found in https://github.com/mandiant/capa-testfiles/tree/master/dynamic.

Then we could handle it analogous to static file limitations (e.g. here

So currently, is it unable to detect .NET samples?

Yes, that's the first idea here.

Can you please explain the issue in more detail? I am still unable to understand where the problem is ( this is my first time seeing the internals of capa).
Here's what i have interpreted:

• runtime APIs used and APIs written in code differ
• currently from the sandbox files, capa is unable to detect a .NET sample

Hence, we need to make capa identify .NET sample(no idea how it's done) and warn users if it is .NET and that's all. Is this correct?

Yes, sounds like you got it.

For static analysis we already handle cases where the analysis may be confusing or wrong (so I provided that as an example).

For dynamic analysis there is probably multiple ways to identify .NET from the analysis archives. For CAPE and VMRay e.g. from the static analysis results (pefile, etc.).

How do I know which ones inside the capa-testfiles/dynamic/capa are dotnet ones? I know for vmray, all are dotnet samples as they that dotnet_version field in their summaries.

you could use file to check if the file contains a .NET assembly. or perhaps check the imports to see if mscoree.dll is loaded. there's a capa rule for this.

https://github.com/mandiant/capa-rules/blob/master/runtime/dotnet/compiled-to-the-dotnet-platform.yml

the files in capa-testfiles/dynamic/cape(pardon me for my mispell) are zips of json data and being new to this codebase, I currently have little to no idea how to interpret it.

ah, sorry, i misread the file path!

i don't know off the top of my head. it may require a little novel research.

for example, you could compare the either the module load or API calls (probably the first few) of .NET vs not .NET in the VMRay dataset, to figure out what a good charactistic/pattern is, and then see if it applies to CAPE too.

again, i think loading mscoree.dll is probably a good indicator, but im not totally sure.

The problem that I am seeing is I don't know a perfect way of knowing if it's a .NET by looking at the json from cape. If there is, then please tell. After that, I can try to find a pattern of how to identify if it is .NET.

according to VT, 2ebadd04f0ada89c36c1409b6e96423a68dd77b513db8db3da203c36d3753e5f is a .NET assembly:

however, the file output embedded in the CAPE report doesn't support this:

but we should be able to use this field to find .NET files.

none of the CAPE reports in our existing testfiles repo are for .NET samples:

we'll have to find a new one and add it to the repo.

What I feel is checking if mscoree.dll is loaded or not should be a good enough indication of it being .NET. However, I can see that some normal PEs can deliberately load that dll and not use it giving out a false alarm. So, should I take the above into consideration and start implementing the logic?

I'd start by obtaining a CAPE report for a .NET sample and inspecting the static fields, i.e. the mentioned file data - additionally, it may make sense to inspect the API trace (but it's probably not even necessary).

Okay. Will start implementing this.

can I use the check that if mscoree.dll is present in the imports in case of vmray as the current structure does not have any other explicit field that can be used for .NET detection? So, I am thinking of searching through imports for dll and if we find mscoree.dll,then we can generate the warning. This will work for vmray but cannot say as such for cape as we don't have cape .NET samples.

I think it's important that we find a test case for CAPE before going too far along. I'll be back working again tomorrow (sorry been off for two weeks) and can help collect the test file.

Also, we would need some more samples in vmray too as currently there is only 1 .NET pe in the testfiles.

@doomedraven can you suggest a source of public CAPE sandbox results? VT doesn't share the raw report archive.

i will provide you one tomorrow from TCR, today is last holiday here

dotnet.json.zip

Great

@mr-tz @williballenthin shall I continue with approach of finding imports and iterating through them to find if it has imported mscoree.dll? The reason being although cape-analysis provide the details about file but the VMRay samples as I have seen do not. So, for keeping the structure of code symmetric, I feel it would be better to use the same idea for all samples. Also, please guide me if there is any particular rule that must be maintained like "a certain module should not be imported in another" or so.

Also, please tell what the warning message should be.

Yes let's move forward with the import strategy. You can use the existing capa rule format and logic to specify "import: mscoree" (or perhaps the function from that DLL) and make it only used for dynamic analysis ("scope: dynamic: file, static: unsupported").

please see how the existing static analysis file limitation rules and warnings are emitted for an example.

Shall I create a new rule under internal/limitation/file or something other directory or try to use some existing rule ( I feel it would be difficult to get a rule specific to our requirements and conditions, especially with scope)?

rule:
  meta:
    name: .NET dynamic sample
    namespace: internal/limitation/file
    authors:
      - "@v1bh475u"
    scopes:
      static: unsupported
      dynamic: file
    examples: # yet to be tested and found
  features:
     - or:
      - format: dotnet
      - import: mscoree._CorExeMain
      - import: mscoree._corexemain
      - import: mscoree._CorDllMain
      - import: mscoree._cordllmain

The above rule is almost same the rule compiled to the .NET platform but I have made it so that it can only be used by dynamic samples. I feel making such a directory for dynamic samples similar to the one present for static samples can help in making it easy to add more limitations for dynamic samples.

@williballenthin what is the password for the cape sample zip that you have shared? I have implemented some code and want to test it against it but capa does not support json.zip format. It works for vmray sample.

try "infected"

@williballenthin It worked! Now, I need to make PRs on capa as well as capa-rules both. I have made and uploaded the changes in the forked repos. Can you please guide me for how shall I proceed with the PRs? Also, is it fine if I continue to communicate like this on github or would you prefer mail for communicating on future issues that I try to solve?
https://github.com/v1bh475u/capa/tree/feat/warn-for-dynamic-dotnet
https://github.com/v1bh475u/capa-rules/tree/feat/dynamic-limitations

Working here on Github works well for me, as long as it does for you, too.

Nice job on the updates! Let's get PRs created for these changes. Have you done this before?

If not, you can use the button here to create a PR:

and in the PR text you can reference this issue, like "closes #1864".

Once that is open, we can review and address any further recommendations, and merge when its ready. Thank you!

@williballenthin I have made the PRs. Please review them whenever you are free.

@williballenthin, I have also made the PR on capa-rules that restructures the limitation rules as per the expected namespace. Please review that too. mandiant/capa-rules#983