Event Date Fields
There are a lot of different dates used on and in events across the Flare application. This guide should help you better understand which dates we use where and what those dates refer to.
Contents
This date is an estimate of the date that we think this event occurred in the wild. For example the date a Forum post was posted. However, the date we use to create this estimate varies from source to source, and therefore though it is highly informative it is not always very reliable. You can look at the table below to see a breakdown of which dates we use of the Creation Date by data source.
Also known as:
- Estimated Creation Date
- Estimated_created_at
- Posted at
- Breached Date Note: not equivalent to Breached At
- Infected At (Installed_at)
- Timestamp
Where do I see this date in Flare?
- On event cards in the event feeds. It is the date by which the events in the event feeds within the platform are ordered and filtered (not in the API, see Materialized At below).
- In the Supply Chain Monitoring table, this date is called Breached Date.
Why can this date be unreliable?
- As this date is pulled from the data sources themselves there is often a risk it is incorrect. For example a Forum has the wrong date setup.
- Sometimes we cannot pull a date from the source itself, and we have to default back to the date that we found the event. This means for a newly added source, for the first time we bring in the content, the best we can provide for Creation Date is the first_crawled_at date, and there isn’t a way to discern old and fresh content on our first pass.
- For stealer logs this date represents the date that the device was infected (not the date the credentials were leaked in the wild). Therefore we rely on the date from the infected individual's computer which could be set up incorrectly, or they may be using a non-Gregorian calendar.
- For leaks from Combolists, we do not have a Breached Date, so we resort to the Materialized At data in place of the Breached Date/Creation Date.
This is the first time Flare finds and then crawls and imports an event into the Flare database.
Also known as:
- First_crawled_at
Where do I see this date in Flare?
In the metadata of events and as the Imported At date for leaked credentials.
This is the most recent time that Flare crawled the data from an event.
Also known as:
- Last_crawled_at
Where do I see this date in Flare?
In the metadata of events.
This is the date that Flare matches an event to one of your identifiers, in other words this is the date Flare establishes that an event is relevant to you based on your identifiers. Therefore, if the matched event falls under the criteria of one of your alerts then this is the date that alert will be sent.
Things to be aware of:
- Upon creation of an identifier, all existing events from the Flare database that match to that identifier that day will have the same Materialized At date.
- If we bring in a new data source into Flare, and events from that source match your identifiers, the Materialized At date will be the date that the new data source events entered Flare.
- If we index new data fields within our existing events (eg., we start indexing phone numbers) then historical events might match your identifiers for the first time. So you will be alerted on ‘old’ events for the first time.
Also known as:
- Materialized_at
Where do I see this date in Flare?
- This is the date by which the Dashboard presents events, if you click to view events directly from the Dashboard you will see this date populated in the search box of the event feed.
- This is also the date by which we Alert you of events that match any of your Alerts.
- It is the date by which the events in the event feeds within the API are ordered and filtered
This is a date that is manually added to events from named leaks when the date of the leak is known.
In the case of combolists, they are imported almost nonstop, so there is no true "leak time", the date you are seeing is the Imported At date. It could have been "leaked" at a very different date, but Flare cannot know.
Where do I see this date in Flare?
On the Source information on Credential Details for leaks in the Credentials Browser.
This is a date that is manually added to events from named leaks when the date of the breach is known. Sometimes breaches happen, and then years later the leak is shared publicly, hence the distinction.
Where do I see this date in Flare?
On the Source information on Credential Details for leaks in the Credentials Browser.
This is the date at which an event was parsed by our scraping processors. For instance, at 2:57:01 we crawl and download a conversation from Telegram, then at 2:57:03 our processing pipeline scrapes it as structured data into our database.
Where do I see this date in Flare?
This is seen in the Advanced tab of Stealer log (infected Devices) events.
Most commonly used name | Other names | Seen where in Flare | Details | Confidence in date accuracy |
|---|---|---|---|---|
Creation Date | Estimated Creation Date Estimated_created_at Posted at Breached Date Infected At (Installed_at) Timestamp | The event feeds cards and in the event Metadata. In the Supply Chain Monitoring page. In the Advanced tab of events. | The date we estimate this event occurred in the wild. | Low. This date is an estimate based on data from third party sources. |
First Seen/Imported At | First_crawled_at
| In the event Metadata, and for leaked credentials. In the Advanced tab of events.
| This is the first time Flare finds and then crawls an event. | High. This is a date computed by Flare. |
Last Seen | Last_crawled_at | In the event Metadata. In the Advanced tab of events. | This is the most recent time that Flare crawled the data from an event. | High. This is a date computed by Flare. |
Matched At | Materialized_at | In the Dashboard, for Alerting and in the event feed of the API. | The date that Flare matches an event to one of your identifiers. | High. This is a date computed by Flare. |
Leaked At |
| In credential details. | The date of a leak for named leaks. | Medium. This is manually annotated by Flare employees. |
Breached At |
| In credential details. | The date of a breach for named leaks. | Medium. This is manually annotated by Flare employees. |
Scraped At |
| In the Advanced tab of Stealer log events. | The time our processing pipeline scraped the data from the (downloaded) page into our DBs. | High. This is a date computed by Flare. |
Data Source | Creation Date |
|---|---|
Infected Devices | Infected at |
Combolist | First seen or matched at |
Market | Item listed at |
Forum Post | Posted at |
Blog Post | Posted at |
Profiles | Registered at |
Chats | Posted at |
Ransom Leaks | Posted at |
Financial Data | First seen |
Pastes | Posted at |
Web Accounts | Registered at |
Source Code | Code committed at |
Result processed at | |
Hosts | First seen |
Buckets | First seen |
Leaked Creds | First seen |
Ads | Ad created at |
Look-alike Domains | Registered at |
Botnet | First seen |
PII & Unverified leaks | First seen |
Potential Stealer logs | First seen |
Ransomware files | First seen |
SEC filings | First seen |
App Store | First seen |
Other found files | First seen |
Notes
- If a value is missing, we will fall back to the First Seen timestamp.
- If once a week on Monday 8:00 we start a batch of Google searches, they will all have the same Creation Date time at 8:00 even if the actual individual searches are then staggered for as long as it takes to perform them.