[Feature Request] Extend Responders/Analyzers to include collection of user input

DarrenSykes commented 4 years ago

Request Type

Feature Request

Problem Description

The current implementation allows observables to be passed to an analyzer, but the other parameters used are fixed.

This reduces the usefulness of some analyzers when there isn't a one size fits all.

For example, we have an analyzer that will find the reference to an IP address in our environment across multiple sources. This is useful when investigating suspicious traffic.

However, the speed of the results is heavily dependent on the amount of history that is examined. We also want to limit the search window because of the potential performance impact on our SIEM.

At the moment we have a fixed window, which is invariably wrong, and results in analysts not using the analyzer but going back to native tools. I'm sure there are many other use cases where this also applies.

Possible Solutions

We could create a HTML form that is associated with each analyzer (much like the existing long and short templates). If the form template is defined, theHive could present the form to the user, then pass the field contents to the analyzer/responder as it's run.

Analyzers/Responders could be written to use the fields that are passed and 'do the right thing'.

In my example, that'd allow us to use a calendar picker for the analysts to use, and we could add some validation in the form that'd prevent large date ranges from being entered.

nadouani commented 4 years ago

This is a challenging feature request that is already on our radar. Cortex analyzers already support what we call free parameters but TheHive doesn't provide a way to let user enter custom parameters.

The FR makes sense, but requires some questions to be answered:

How to have analyzer definition files declare their params
How to deal with that in Cortex
How to handle bulk analysis in TheHive using analyzer that require parameters ...

We need to find some time for this.

DarrenSykes commented 4 years ago

For bulk analysis, it would make sense (to me) to set defaults for each parameter and for bulk and API requests to use those defaults; for me this is an interactive feature.

It could be my bias due to the way we use the platform, but I’d imagined this would be an extension to thehive that used existing Cortex functionality - analyser definitions would be no different, it’d just be how the hive populated the parameters when it called Cortex.

nadouani commented 4 years ago

TheHive needs to know in a generic way, what are the parameters that an analyzer could get as input. And based on that, TheHive should be able build the forms automatically.

DarrenSykes commented 4 years ago

That’s one way of doing it. The other is to allow forms to be defined as html which contains the fields (and would allow them to be prettified and JavaScript added, much the same way we use the same approach in reports to format the output - we use JavaScript for allow tables of results to be sorted etc, base64 to be decoded etc).

Either way would work in truth, I’d prefer the flexibility, but an automated form generator would be fine too.

vletoux commented 3 years ago

Here is my contribution to this feature.

The problem is that the responder is triggered by an API called, that means that The Hive is the master and Cortex the slave. Because Cortex executes only orders, this is quite challenging to implement. In another project of mine, I implemented some kind of "reverse pattern", allowing a slave to query data on the master.

Here is a graphical summary

This requires the following set of changes:

extend the interface API right now, the only answer a Cortex plugin can have is "done" or "failed". This require to extant the protocol for a 3rd answer which is "query data". Create a json field with title, header, list of field. Each list of field has a type, a label, an potentially predefined answer. Exemple: label: Server, type = string, value = 192.168.0.1 Add a button OK, Cancel, Hide (see analyst assignement below)
with TheHive UI If TheHive has to query data, it has to show a popup. This popup need to be contextualized (asked on the right analyst, or if the case is closed, ...) I propose to reuse the excellent live feed. If the analyst is on the case that initiated the query, ask him. If there is other analyst, ask them. Else, show the query on the feed with a link to display the popup Allow a maximum time to answer, before cancelling the request. This time can be set by the plugin, but with a global time override by the application to avoid stalled request Enable the button "Hide", in order to allow to swith the UI to another analyst.
with cortex This is the tedious part, because existing plugin must not be changed, and the cortex code should have nothing to with the intermediate API answer. I managed to find a workaround. In the current code, the python code of the responder is called directly. You obviously need to run it in a thread.

Before this thread is started, an event is created. When this thread is running, the normal cortex plugin is doing this job Than at the end of the main function, the thread is ending. It raise the event. The waiting function then handle it gracefully.

When a UI has to be asked, a cortex API (whose logic is hidden in the Responder object inherited by the responder) raise the event, with attached the UI information to be asked. If the cortex responder is called again with the UI answer, the thread resume. If not (aka, time out), the function is resumed, but with an exception.

Example from the cortex responder stand point.


class Test(Responder):
   def askForUI:
          ui = new ResponderUI()
          ui.Title = "test"
          ui.Fields = [{"name": "server", "type": "string", "value": "192.168.0.1"}]
          try:
               answer = responder.ShowUI(ui)
           catch(UICancelled):
                #failing gracefully

I'm copy pasting some image of this pattern I've made in c#, in order to give you idea. 1) API code on the server side (equivalent of Cortex API entrypoint)

2) The code starting the plugin [START]

3) Function called by the plugin which hand over the result and get the answer [RESUME]

4) UI interaction in the middle of the plugin

TheHive-Project / TheHive