MISP (originally Malware Information Sharing Platform) is a platform to share, store, and correlate Indicators of Compromise (IOCs) from targeted attacks, threat intelligence, or even financial fraud information. One of the reasons underlying MISP’s success is its extensibility via third-party modules. However, as the number of contributors increases, coordination and distribution can quickly become a challenge. To solve this issue, MISP’s authors created a satellite project called MISP modules.
Before joining the NSX family, we at Lastline contributed three different modules to the MISP project in order to better integrate MISP with the sandbox that is now part of the NSX Advanced Threat Analyzer (ATA) product offering. The main idea was to enrich the file indicators referencing an artifact with behavioral information extracted by detonating the artifact in the sandbox, or by retrieving the analysis result of previous detonations. We accomplished this by relying on three different modules:
- lastline_submit: An enrichment module used to submit new files to the sandbox; as dynamic analysis requires some time to terminate, the output of this module is an external analysis link represented by a new MISP attribute.
- lastline_query: An enrichment module to expand a MISP attribute containing an external analysis link into objects detailing the result of a detonation.
- lastline_import: An import module to be used when importing the results of a specific detonation without requiring a MISP attribute as a starting point (useful when creating a MISP event from scratch).
In this blog post, we will detail each module’s functionality and present a quick walkthrough of the steps required to configure and invoke them via the MISP web interface. As future work, we will also release a new version of these modules containing important updates but also providing better alignment to the current product naming. Another blogpost will cover all these updates and be published during the next quarter.
Installing the modules is just a matter of downloading the latest version of the MISP module distribution available at https://github.com/MISP/misp-modules. Be sure to download the latest release, or at least one including commit #66bf650, as it contains a set of important fixes that we recently applied to the lastline_submit module. Once installation is complete, remember to start (or restart if this was an update) the module service.
Configuring MISP modules is done via the user interface. However, based on the type of module, you may need to enter the configuration data in a different section. For example, expansion modules (the type associated with lastline_submit and lastline_query) are configured inside “Administration -> Plugin Settings -> Enrichments”, while import modules configurations (e.g., lastline_import) are found inside “Administrator -> Plugin Settings -> Import”.
Different modules require different configuration settings: Figure 1 shows the requirements for lastline_submit and lastline_query. The lastline_submit module requires access to the NSX ATA Analyst API in order to submit files, and thus requires an API key, a token, and the URL of the Analyst API endpoint (the default is https://analysis.lastline.com but one can change it to match one’s installation, if on-premise). The lastline_query module, meanwhile, simply retrieves the result of an analysis, and so needs only the username and password credentials required to login into the NSX portal.
Figure 2 shows the configuration needed by lastline_import. As was the case for lastline_query, only the username and password to access the NSX portal are required.
In MISP, there are different types of modules. Expansion (or enrichment) modules take as input an existing MISP object or attribute and aggregate additional information in the form of additional objects and attributes, leading to a tree-like structure. Import modules, on the other hand, are used to create an object from scratch when no pre-existing MISP attribute is available. This is the reason the lastline_query and lastline_import modules are conceptually similar — they both “aggregate” new information — but serve different purposes: while they both “explode” an analysis link into multiple objects and attributes representing the result of a detonation, in one case the starting point is a MISP attribute (the external analysis link), and in the other an attribute is not required and the analysis link can be manually provided. In the next sections, we will show some actual examples.
The lastline_query module expands attributes containing external analysis links. This enrichment module can be invoked by clicking the * (star) symbol in the Actions column. Figure 3 shows lastline_query correctly listed as an option for enrichment, while Figure 4 gives an idea of the kind of output returned when enriching an attribute. In this specific example, the enrichment even added a number of tags detailing the TTPs (in MITRE ATT&CK format) detected during the detonation process.
When creating a MISP event from scratch, a threat analyst may want to import the result of an analysis (along with all the file objects) without creating the necessary MISP attributes in advance. This is possible via the lastline_import module. Figure 5 shows how one can input the external analysis link using the “Populate from” shortcut, without being required to submit a file or create a MISP attribute in advance. Note that the output after invoking this module mirrors what we would get with the lastline_query module displayed in Figure 4.
To submit a file or an attachment to NSX Advanced Threat Analyzer for detonation you need to use the lastline_submit module. As with other enrichment modules, the logic is invoked by clicking the * (star) next to the relevant attribute. Since detonation is likely to take a few minutes, the module returns immediately with an external analysis link conveniently encoded into a MISP attribute. If the sandbox has previously detonated the file and a cached result is already available, the module adds the tag “workflow:state=complete”; otherwise the “state” key is set to “incomplete”. The end result is shown in Figure 6: a new MISP attribute with an external analysis link is added to the event (ready to be further enriched via the lastline_query module) and a new tag flags the analysis as either complete or incomplete (in the example, incomplete).
Ideally, (and as done by similar implementations — see https://www.vanimpe.eu/2019/05/07/submit-malware-samples-to-vmray-via-misp-automation/) an external CRON job would access the MISP instance via its API, fetch all MISP attributes tagged as incomplete, and run the lastline_query module automatically. A future version of our MISP modules will include this missing piece.
In this short blog post we have described three MISP modules that can be used to better integrate a MISP instance with NSX Advanced Threat Analyzer. As the workflow associated with MISP is often business-specific, we provide two different modules to import the results of a detonation: lastline_query when a MISP attribute is available, and lastline_import when creating a MISP event from scratch. Submission of new samples is done via the lastline_submit module.
We will soon refresh the MISP modules to reflect recent product enhancements, so if you find some features lacking, know that a new update (and a new blogpost) will soon be published. In conclusion, as with other MISP modules, these modules are community supported; bugs should be reported in the MISP modules GitHub project.