Related files feature

[vandir]

Feature Category

• [ ] Correctness
• [X] User Interface / User Experience
• [ ] Performance
• [X] Other (please explain)

Describe the problem

We need a way to upload a file associated with a sample that should not be analyzed or investigated, like a .IDB (Ida database) file, a .pdf report or other goodware supporting data but simply shown as download links in the custom attribute section or in a new "Related files" tab like the following:

Describe the solution you'd like

The related files should be shown as download links in the custom attribute section or in a new "Related files" tab. The related files should not be shown in the samples list because they are not malwares.

Describe alternatives you've considered

We see that there are only 3 type of objects: sample, blob and config. We maybe need an additional object type named supporting_data or associated_file that must not be analyzed and listed in "samples" but shown in a new tab (like what happens with config).

We also considered the opportunity to create a plugin that intercept and abort the upload process when the uploaded file is a .IDB or .PDF but we miss a webhook like before_file_creation that could be used to:

1. filter out the uploaded file (that is abort the upload process)
2. instead upload the file in third-party service (or in an alternative bucket of the minio instance)
3. create a custom attribute with the download link in the parent sample

Is it reasonable to have this feature in the MWDB project or it is too much "case-management" oriented? That is will you accept pull requests about this feature?

This issue is somehow similar to #560.

[psrok1]

Sure, I like the idea to exchange files that are malware-related but are not actually malware samples!

Another use-case are encrypted/compressed payloads by some not-yet-known algorithm that are stored in MWDB for further analysis. That's pretty common in CERT.pl as well. These can be uploaded directly to MWDB, but we don't want these partially-processed artifacts in the actual sample list.

Choosing different storage buckets is not that necessary, but might be actually useful to have these files physically in separate place e.g. to not include them in mquery scanning. But maintaining multiple storage providers sounds like another huge pull request.