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 https //docs flare io/event date fields#hmlli https //docs flare io/event date fields#p2hkt https //docs flare io/event date fields#o 9pk https //docs flare io/event date fields#lknje https //docs flare io/event date fields#ttyj4 https //docs flare io/event date fields#nts0j https //docs flare io/event date fields#yjpdh https //docs flare io/event date fields#raqfd https //docs flare io/event date fields#8qsc https //docs flare io/event date fields#gemad creation date 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 first seen 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 imported at this is a date that is used exclusively for leaked credentials and reflects the date at which a set of credentials are imported into our database and become available in the global search and credentials browser where do i see this date in flare? in the credentials browser as the imported at date for leaked credentials last seen 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 matched date 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 matched 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 matched at 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 events in the tenant feed are sorted if you choose the sort by matched date option in the sort picker it is the date by which the events in the event feeds within the api are ordered and filtered leaked at 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 breached at 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 scraped at 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 event date summary table 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 first crawled at in the event metadata, and 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 imported at for leaked credentials in the credentials browser this is the time a set of credentials is imported into flare's database 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 creation date by data source table 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 google result processed at hosts first seen buckets first seen leaked credentials imported at 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