Search | Query Syntax | Entities#

To search for Entities, from the left sidebar, select Search icon> Search then go to the Entities tab.

You can search for Entities with:

You can also save queries as Datasets and load the queries existing Datasets are based on.

Attributes#

Attribute

Looks for

Example values

created_by

Entities whose user ID integer value matches the specified pattern or literal.

*, 1

data.confidence.value

Entities whose observable maliciousness confidence value matches the specified pattern or literal.

high, medium, low, none, unknown

data.kill_chain_phases.kill_chain_name

Entities whose kill chain phase name matches the specified pattern or literal.

reconnaissance, weaponization, delivery exploitation, installation, command and control, actions on objectives

data.kill_chain_phases.name

Entities whose official or standard name matches the specified pattern or literal.

LMCO Kill Chain

data.kill_chain_phases.ordinality

Entities whose integer order value matches the specified pattern or literal.

This value defines the order of a kill chain phase within a kill chain.

1, 2, 3, 4, 5, 6, 7

data.observable.title

Entities with at least an observable whose title/header matches the specified pattern or literal.

Mirai botnet-related observable

data.producer.identity.name

Entities whose data producer name matches the specified pattern or literal.

The Entity per producer gauge on the dashboard used this field to display the total amount of ingested Entities, based on the corresponding producer.

phishtank, hailataxii

data.sightings_count

Entities with at least an observable that has actually been sighted.

This is a counter whose integer value reports the number of sightings recorded for the corresponding observable.

*, 1, 2, 3

data.type

Include Entity types in your query to have the search results include only Entities of the included type(s).
Check our documentation on Entities to see which Entity types exist.

data.type:report OR data.type:note

exposure.sighted

Entities with at least an observable that has actually been sighted.

When Entities are associated with a sighting, they are exposed.

Entities with exposure.sighted:true have a data.sightings_count value of at least 1.

true, false

meta.source_reliability

Entities whose data source reliability matches the specified pattern or literal.

A, (A B C)

meta.tlp_color

Entities whose TLP color matches the specified pattern or literal.

RED, AMBER, GREEN, WHITE, NONE

meta.tags

Entities whose custom tag values match the specified pattern or literal.

malware, ransomware

tags

Entities whose custom tag and standard taxonomy values match the specified pattern or literal.

malware, ransomware

_exists_:"attached_files"

When added, returns only Report Entities with files attached. When excluded, returns Report Entities without files attached and all other Entities.

_exists_:"attached_files", !(_exists_:"attached_files")

More granular search

There are more attributes you can search with. Use the search bar’s autocomplete to help you find attributes to use, see individual Entity documentation for more information.

Date-time attributes#

There are a number of Entity attributes that you can use to search by date and time. The most commonly used are listed below along with their explanations.

Attributes requiring date-time#

The attributes listed in the drop-down below require you to specify a date-time.

Date-time attributes

Entity attribute

Description

created_at

Entities whose creation date matches the specified pattern or literal.

last_updated_at

The date and time that an Entity’s details were last edited in EclecticIQ Intelligence Center.

data.producer.time_produced

Entities whose creation time at the data producer matches the specified pattern or literal.

This field is specific to incidents.

data.producer.time_received

Entities whose reception time at the data producer matches the specified pattern or literal.

data.reporter.time_produced

The date and time that an incident was reported.

This field is specific to incidents.

You have to type the date value as a full string (for example: 2020-01-25T12:35:00+0200).

data.time_first_malicious_action

The date and time of the first malicious of an incident.

This field is specific to incidents.

You have to type the date value as a full string (for example: 2020-01-25T12:35:00+0200).

data.timestamp

Entities whose data creation time matches the specified pattern or literal.

data.valid_time_positions.start

The start of the time window during which an indicator is valid.

This field is specific to indicators.

You have to type the date value as a full string (for example: 2020-01-25T12:35:00+0200).

data.valid_time_positions.end

The end of the time window during which an indicator is valid.

This field is specific to indicators.

You have to type the date value as a full string (for example: 2020-01-25T12:35:00+0200).

meta.first_ingest_time

The date and time of an Entity’s most recent ingestion into an organization’s cluster of platforms.

You can only search using a single value.

meta.ingest_time

The date and time of an Entity’s ingestion into a particular platform.

You can search using a single value or a range of values.

meta.estimated_observed_time

The date and time when an Entity is estimated to have been first observed.

You can search using a single value or a range of values.

meta.estimated_threat_start_time

The date and time when the threat posed by an Entity is estimated to have started.

You can search using a single value or a range of values.

meta.estimated_threat_end_time

The date and time when the threat posed by an Entity is estimated to have ended

You can search using a single value or a range of values.

Format#

Use only ISO 8601 date-time formats:

  • YYYY-MM-DD

  • YYYY-MM-DDTHHZ

  • YYYY-MM-DDTHH:mmZ

  • YYYY-MM-DDTHH:mm:ssZ

As a complete example, 12:35 p.m. on 25 January 2020 in Bucharest, Romania would be expressed as 2020-01-25T12:35:00+0200

Single dates & date ranges#

You can specify single dates or date ranges in your queries.

When using single dates, Elasticsearch only compares date values; it ignores time values and doesn’t account for timezones. As a rule, using date ranges in your search queries is more accurate.

To specify ranges, enclose them either square or curly brackets:

  • [<min_datetime> TO <max_datetime>]

  • {<min_datetime> TO <max_datetime>}

Note

The TO operator must be written in uppercase.

Examples#

Query string

Description

meta.ingest_time:["2020-01-01T00:00:00" TO *]

Returns all Entities that were ingested on and after 1 January 2020

meta.ingest_time:{"2020-01-01T00:00:00" TO  "2020-01-04T00:00:00"]

Returns all Entities that were ingested on 2 and 3 January

meta.ingest_time:["2020-01-01T13" TO "2020-01-01T14"}

Returns all Entities that were ingested on 1 January 2020 from 13:00 up to but excluding 14:00

You can also use the following shortened syntax:

Query string

Description

meta.ingest_time:[now/d TO *]

Returns all Entities that were ingested today.

meta.ingest_time:[now/M TO *]

Returns all Entities that were ingested this month.

meta.ingest_time:[now-24h TO *]

Returns all Entities that were ingested during last 24 hours

User timezone

If you specify a timezone in your query, Elasticsearch ignores your user timezone for the actual search. However, the search results are displayed according to your user timezone.

For example:

  • User timezone: CET (+0100)

  • Entity ingestion date-time: 21 Feb 2020 at 7:00 a.m. GMT (+0000)

  • Search string: meta.ingest_time:["2020-02-21T06:30:00+0000" TO "2020-02-21T07:30:00+0000"]

The Entity appears in the search results, but because the user timezone is an hour later, the Entity is displayed with a timestamp of 8:00 a.m.

This may be confusing. Unless you need to share results with users in different timezones, it is preferable to avoid specifying a timezone in a search query.