Data Breach Monitoring: New Evidence is Not a New Infection

A credential record shows up today with an exfiltration date a few months ago. If your monitoring pipeline filters it out as old, the account owner may never learn about an exposure. If your alert calls it a compromise that happened today, you invented a timeline.

The November 12, 2026 announcement from the Netherlands Police about Operation Endgame describes a recent recovery effort with that distinction in view. Authorities dismantled CastleRAT infrastructure during the international action week and seized the private data that was stolen. The police stated that CastleRAT data was available on Check Your Hack and that more personal data would be available in the following weeks. The announcement describes the evidence recovery and availability, not when the infection occurred to every victim.

New evidence is relevant for data breach monitoring, even if the underlying theft is old. Use the collection time to identify incoming evidence and retain the reported event time for further analysis. Neither timestamp should replace the other.

A late-arriving record missed by a recent-infection filter

As a synthetic example, consider an organization monitoring its verified domain. A record for a service account for an employee shows up on November 14th. The source shows the data was exfiltrated on August 20. The Identity team has no case for this exposure.

A rule discards a record if the record contains an exfiltration date older than seven days. That rule answers “was something recently stolen?” It doesn’t answer “does the application learn something new?” The owner loses the chance to compare the exposure that happened in August with other security-related changes.

Accept a record into the review queue, because it is new evidence. The record should show that historical exposure was newly reported, show an exfiltration date of 20 August, and show 14 November as the application’s receipt date. The record should leave the validity of the credentials currently in use unassessed.

The records answer different questions.

Webz.io’s Data Breach Detection API provides structured records related to infostealer logs, data breaches and combination lists. Webz.io’s record documentation states that crawled_date is the time Webz.io collected a record. For context of infostealers, the field device_info.exfiltration_date states the time data was exfiltrated, and for data breaches, the field breach_info.breach_date states the time a data breach occurred. Use those definitions only if the related field is included in the record.

The application’s receipt time is a different time. That time may be later than crawled_date if there is an outage or delayed processing. Do not rename it “infection date” merely because it is the easiest time to determine.

The time of publication of the data set is yet different. A data set may have been stolen and published later. Store the field names of the time stamps and the original records so an analyst can determine the actual record received by the application.

The reported gap between the August theft and the November receipt is evidential material to be investigated. It does not demonstrate that the attacker retained access during that time.

Earlier evidence requires a current decision

What changed after August 20? A dated password reset may have resolved the exposed password. However, it does not demonstrate that associated sessions and other forms of authentication were also removed. Align the exposed data with the changes that were documented.

An account removed before November may warrant a different response compared to an account still being used on a daily basis. Verify removal of the account. If the responsible team cannot establish what happened, keep that uncertainty in the case.

Age should guide the investigation and not suppress the finding.

Test both old and unknown dates

Run the same synthetic record through the integration, this time with the exfiltration date removed. It should still be reviewable with the event date set to ‘unknown.’ Setting that date to November 14 gives a false sense of precision and blends the historic and ‘unknown’ cases with the cases that have a defined, recent event.

When the same identifier is played again, the application should recognize evidence that it has previously accepted and retain the history of the receipts. A repeated delivery should not be treated as a second infection. If more up-to-date information results in a change of the record, the change should be made and the reason for the change should be indicated. The earlier record should not be erased.

Look at the actual alerts and the exported reports and don’t just rely on the database. Both should distinguish between a receipt and reported theft. Have a responder say which date should be the evidence for the investigation; if they say the receipt date because the other date has disappeared, the integration has failed.

Stay within the domains and identities your account is authorized to monitor. Webz.io gives the exposure evidence; your application decides how to queue it, how to time-stamp it, and how to connect it to the owner’s security records. The most helpful alert is the one that reaches the right owner without claiming when an undated compromise began.