Indicator false match on ipv6

Elastic Security
#1

I received a ipv6 match (destination.ip) from an indicator however the destination ip doesn't exist in my threat intel feed!

I've linked my detection rule, the match event as well as the CSV of the threat intel feed (all just public feeds).

misp threat intel

rules

match

Any ideas why is this is happening or is there anything I've missed?

#2

It looks like in that source document you have matched would have been this ip:

  "destination": {
    "ip": "ff02::2"
  },

to an item in that feed.

What I tried out real quick was I parsed out that csv file into an index and then did a query like indicator would have but didn't see the ff02:2 match.

Could you do this hand query on your side and see if it matches something in the list within your dev tools?

GET filebeat-*-misp-*/_search
{
  "query": {
    "terms": {
      "ip": [
        "ff02::2"
      ]
    }
  }
}

What I'm wondering is if there is a problem somewhere with the ingest and it has populated a record in one of your threat lists with the ff02::2

#3

Thanks @Frank_Hassanabad, still no matches :slight_smile:

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 0,
    "successful" : 0,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : 0.0,
    "hits" : [ ]
  }
}
#4

Because the lists are usually smaller than the data sets, we do a match from the list to the events but either direction of the search I wouldn't think would matter. This is usual as this is the first time we have heard of a false positive matching from a threat list.

Would it be possible to let me see the mapping of your threat indexes?

GET filebeat-*-misp-*/_mapping
#5

There aren't any mappings really {} as it inherits the mapping from filebeat-* I would think (see Filebeat Apache Module Change Index Name)

What do you mean "lists are smaller than the data sets"?

#6

I was wanting to see if both destination.ip fields are of the same data type which would be ip and match my side of trying to see if/where a bug might be on this one.

What do you mean "lists are smaller than the data sets"?

In most cases the lists are smaller than the 5 minute blocks of events/data sets, so we pull in the threat intelligence in chunks and then match that against the data set rather than the other way around.

The code for this rule type isn't really complex/fancy from an engineering perspective. It just pulls in the list in chunks and then queries against the dataset.

This is the first time though I have heard of a false positive occurring which could indicate a "one off bug" we might have or possibly a mapping difference where somewhere there is a CIDR that is causing a match with a ip_range.

Have you seen this false positive just once or is it a reoccurring reproducible false positive that is happening?

#7

Let me check - I turned it off after it triggered a dozen times.