Introducing the "Shared File (Re)Opened" Incident
A few of our customers have reported receiving unexpected "Shared File Opened" alerts from their Canary File Shares, and are confused about the cause. These events are often the result of a Canary File Share being opened on a host (often the customer's PC itself, as a test measure) which rightfully triggers the original alert. However, sometime later this "phantom read" occurs causing a second alert and possibly triggering an incident response.
Why This Happens
Our investigations show that (typically) Windows caches the network file path in a variety of ways, and re-opens the same file in the background at a later stage. This varies depending on file type, installed file readers on a host, and even the OS itself.
Why We Don't Ignore These Alerts
In solving this, one option would be to simply ignore alerts which look like cached file reads. However, we feel very strongly about always alerting you when suspicious activity is detected on your Canary, so this approach is a non-starter. At the same time, it is a different risk profile to the regular Shared File Open. It makes sense to signal this to customers, so we've added a new incident to the Canaries called "Shared File (Re)Opened".
What This Means
What this means is that if a specific file in your Canary File Share is opened by the same user on the same host as before; instead of alerting you to a "Shared File Opened" incident, we will be sending you a "Shared File (Re)Opened" alert instead.
This new alert assists you with the history of these incidents and helps you get to the source of repeated opens, so that you can more easily and quickly gauge the severity of the incident.