Skip to content

Potentially problematic time filter in Elastic query #403

@regulartim

Description

@regulartim

There might be a problem in the Elastic query in greedybear/cronjobs/base.py:

q = Q(
            "bool",
            should=[
                Q("range", timestamp={"gte": gte_date, "lte": "now/m"}),
                Q("range", end_time={"gte": gte_date, "lte": "now/m"}),
                Q("range", **{"@timestamp": {"gte": gte_date, "lte": "now/m"}}),
            ],
            minimum_should_match=1,
        )

Some entries in Elastic have multiple of the fields that are checked, e.g. the entries from Honeytrap. These fields may have different values. It seems like the end_time field uses UTC time while @timestamp uses the local time of the TPot instance. This may lead to Greedybear extracting an entry multiple times, once when UTC time matches the criteria and a second time when the local time matches.

A comment in greedybear/cronjobs/base.py says that this kind of query is necessary due to honeypots have different column for the time. But when I query my TPot instance, it looks like the @timestamp is present for all instances.

{
  "query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "@timestamp"
        }
      }
    }
  }
}

This query returns no documents on my instance, so all of the 18 active honeypots seem to use the @timestamp field.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions