Doubts about Filebeat Threat Intel Module [7.12.0]

Hi, everyone

I have been testing with Filebeat Threat Intel module in order to get events from MISP. I have some doubts regarding configuration:

  1. I have to disable every input plugin because they are enabled by default. Should they be disabled by default ?

  2. From my point of view it would be a good feature add GeoIP for threatintel.indicator.ip in order to know the location.

  3. It seems that when there are not events in the time range the plugins shows an Error. Should be a Warning?

  4. How the module deals with duplicates?

Here you are my config:

- module: threatintel
  abuseurl.enabled: false
  abusemalware.enabled: false
  malwarebazaar.enabled: false
  anomali.enabled: false
  otx.enabled: false
    enabled: true
    var.input: httpjson
    var.url: "https://<misp-ip>:443/events/restSearch"
    var.api_token: "<misp-token>"
    var.first_interval: 24h
    var.interval: 12h
    var.ssl.verification_mode: none
- convert:
    - from: "@metadata.pipeline"
      to: "fields.pipeline"
logging.level: warning
 hosts: ['<my-apache-kafka>']
  topic: misp
  client_id: misp

Thanks in advance,



Currently when u enable a module, all the filesets are enabled by default as well. For the GeoIP, that could be added easily. I'd have to see about the error vs warning since I haven't touched the threat intel module yet.

Hi, @legoguy1000

I have found duplicated events after the second interval. I would like to know how this module deals with it.

Thanks in advance

Unfortunately they are not disabled by default. See this issue: [Filebeat][proposal] Disable filesets that are not configured · Issue #17256 · elastic/beats · GitHub

1 Like

Regarding the duplicate events, I have seen a discussion about this before. @andrewkroh check me on this but looking at the threatintel.misp module vs the deprecated misp.threat module, the misp.threatmodule has as part of its local processing evt.Put("@metadata._id", evt.Get(""));. The threatintel.misp module doesn't seem to set the @metadata._id at all which would allow duplicates. Looks like the threatintel.abuseurl module has

  - fingerprint:
      fields: [""]
      target_field: "@metadata._id"

It looks like old version uses the Event.Attributes.uuid as the document _id. The description of uuid is at misp-rfc/ at master · MISP/misp-rfc · GitHub.

I think setting _id is a good safety mechanism. I am concerned that the same uuid is used for updates. This means that any update to a MISP record will cause an _id collision. And because Filebeat users are typically assigned the create_doc privilege this will cause the updates to fail.

I don't know if the intended behavior of setting _id was to update the MISP record in Elasticsearch or just to prevent duplicates. If the intent was to prevent duplicates then the new module could go the fingerprint route and incorporate the uuid and misp timestamp since it should change if the record is updated.

1 Like

Hi, @andrewkroh

I think it could work.

Thanks :slightly_smiling_face:,


Hi, @andrewkroh

Should we create an issue on GitHub ?


Hello @RdrgPorto, @andrewkroh @legoguy1000,

Hopefully I can shed some light on some of these questions, please let me know if there is something I didn't cover.

  1. For the question around enabling/disabling, it seems to have been covered already by Andrew, and its something that is of course up for discussion, following that issue seems to be the best approach.

  2. The GeoIP processor is absolutely a valid point for the threatintel.indicator field, I will bring this up and see if we want to enable this as well.

  3. Changing the logged message from error to debug has been implemented in 7.12.1+7.13 I believe, I will check if MISP is using that new option as well, it should now only be logged if debug is enabled. The reason is that there will always be an empty response for modules that uses pagination, once it reaches the last page, so leaving it at warning level is still too high, as we only want to show this during debugging.

  4. The duplication between the old and new misp module is a bit different, and the new MISP fileset which is part of the threatintel module should be overwriting the updates because of the op_type that is set, it also uses a different API than the old MISP module, as the old uses attribute/restSearch, while the new uses event/restSearch, the format of which the events come back is a bit different.

When we receive any of the raw events, they all look like this: beats/misp_sample.ndjson.log at master · elastic/beats · GitHub

All attributes related to an Event will be split up into its own document, each Event has its own uuid, while each attribute also has its own uuid.

The processor that is used by the module, documented here: beats/config.yml at master · elastic/beats · GitHub

Will first set the document_id to the uuid of the attribute:

  - decode_json_fields:
      fields: [message]
      document_id: Event.Attribute.uuid
      target: json

After that, to allow documents to be overwritten, so that instead of duplicates, the old document is replaced by a new one, we overwrite the default op_type field of the metadata:

  - script:
      lang: javascript
      id: my_filter
      source: >
        function process(event) {
            event.Put("@metadata.op_type", "index");

The intended behavior here is that duplicated events should be overwriting the existing one, instead of creating a second event.

Once filebeat has received the response from the API, it will take the timestamp from the newest event it receieved, and use that as a filter for the API on any new API calls after that, so that we do not end up receiving the same events multiple times, causing constant overwrites for example.

This is done by setting cursor.timestamp to the request body, and if this is the first time filebeat starts up and cursor.timestamp do not exist it will look back the configured value on var.first_interval in your configuration file.

- set:
    target: body.timestamp
    value: '[[.cursor.timestamp]]'
    default: '[[ formatDate (now (parseDuration "-{{ .first_interval }}")) "UnixDate" ]]'

Cursor.timestamp is magically set based on the timestamp from the last event like so:

    value: '[[.last_event.Event.timestamp]]'

Hopefully this clear things up :slight_smile: And thanks for all the feedback, keep it coming because we are always trying to make the modules better!


Hi, @Marius_Iversen

I have been testing with this module and I have found out duplicated events. As you can see in the next screenshot, the same attribute is duplicated in Elasticsearch:

If I correctly understand your explanation, the Elasticsearch document id should be the MISP attribute uuid. Nevertheless, I see that _id does not match MIPS uuid.

Moreover, if I execute Filebeat module (Filebeat 7.12.0 with Elasticsearch 7.9.2) several times, it duplicates the results every time not taking into account the timestamp as you explained.

Here you are some screenshots of MISP:

Thanks in advance,


Using different versions might have some undesired effects, however I do believe that's not what is causing your issues right now.

I will see if I can reproduce it and come up with a fix if needed, will let you know how it goes.

1 Like

Hi, @Marius_Iversen

Thank you very much :smiley:


Just removed my older posts, as they would have been conflicting with the results.

We ran some tests with and without the uuid setting for the filebeat module against our own misp setup and saw that the expected behavior did indeed happen, so this seems to be something specific to your setup:
Below is the picture, the first event is with the UUID option removed, and the rest is with the UUID like it is today, the field is the _id of the documents.

Is this from a beat that has been updated multiple times? Maybe it has some conflicting yml files from older versions?

The ID fields from your screenshots is not what you want to match:
threatintel.misp.uuid is the Event UUID. is the Event ID. is the Attribute ID.
And the document._idshould be the UUID of the Attribute, though in your case its not for some reason.

Can you try to set a file output in filebeat and see how the output files looks like? While most of the parsing is gone, since that happens on ES, you should have a proper _id field in the @metadata section of the resulting output.

1 Like

Hi, @Marius_Iversen

I have tested with Elastic Stack 7.12.1 (Elasticsearch, Kibana & Filebeat) and it works. I think that this issue is related to Elastic Stack 7.9.2.

Thanks for all,