discuss enhancements for the CAPE extractor

[yelhamer]

This issue will serve to keep track of enhancements that are to-be-added to the CAPE extractor after basic functionality is achieved.

For the time being, the current features are in queue:

• [x] make the report-parsing more modular: for the time being, the cape extractor parses the report in a simplistic manner; an empty dictionary is instantiated, and then artifacts are added to it one by one, which will make updating it a hard task. Therefore, it would be nice to have a global list of artifacts containing the artifact's name and location within the report, as well as a method that goes through that list and extract the necessary artifacts; this will make it easier to support other extractors that provide similar reports.
• [ ] add the ability to support sample submission: add a class method that takes in a filename, an api url, and an api key, and returns a CAPE extractor object.
• [x] make it easier to generate cape extractor objects from a filename: consider adding a helper function that takes in a filename and returns a CAPE extractor object.

[0x534a]

I just wanted to leave the information that I finally found some time to release the PoC code of dynmx as open source. You can find the code in the dynmx repository.

The tool is able to parse CAPE sandbox reports and to store the parsed data in an object-oriented data model. It possibly includes some code which can also be helpful for this project. The tool is also able to extract OS resources like accessed files, registry keys and network resources from CAPE sandbox reports.

[yelhamer]

point 1 (making the extractor more modular) has been addressed by adding a pydantic model for the CAPE extractor (#1729). It would be nice to do the same for future sandbox feature extractors as well.