A canary-token document from a decoy file share called back — what does that callback actually prove?

## What the token is and how it fires A canary token is a document, spreadsheet or similar file seeded with a reference to a remote resource under your control. When something renders the file, the renderer fetches that resource, and the token service records the fetch. Put such a file in a decoy share — a share visible in the file server's share list but referenced by no mapped drive, no script and no documentation — and you have a tripwire on the path between enumerating shares and reading what is in them. The callback record is the whole observation surface. It typically carries a token identifier, a memo you set at creation, a timestamp, a source address, and a user agent string from the fetching client. That is a short list, and reading it precisely is the skill. ## The two facts you actually have 1. **Something processed the file.** Not necessarily a person opening it deliberately — processing includes previewing, indexing, scanning and detonating. 2. **The processing host could reach the token service at that instant.** The fetch happened over the network, so egress existed at that moment from wherever the render occurred. Everything else in your write-up is inference and must be labelled as such. ## What the fields do not give you **The source address is rarely the opener's address.** Inside a corporate estate the fetch usually leaves through a proxy or network address translation gateway, so the token service records the estate's egress address. That collapses attribution to "someone or something inside", and recovering the internal client means correlating against other records — which is investigation work, not something the callback hands you. **The user agent names the renderer, not the person.** A word processor, an operating system preview handler, a link-following mail security product, a data-loss-prevention crawler and a search indexer all produce different strings, and none of them is an identity. A user agent belonging to a scanning product is a strong hint the file was processed by automation rather than read by a human. **Nothing proves copying or exfiltration.** The file may have been opened in place on the decoy share. A token tells you it was *rendered*, never that it was *taken*. **Nothing proves malice.** Backup verification, content indexing, migration tooling and an administrator checking what is in an unfamiliar share all render files. This is a real fire from a real interaction that may be entirely benign. ## What silence proves: nothing Absence of a callback is not evidence that the document was untouched. The file may have been copied and opened on a segment with no egress, or on an isolated host; the renderer may have blocked the remote fetch, which is the ordinary behaviour of a document opened in a protected or read-only mode with external content disabled; or the fetch may have been blocked by your own outbound filtering. Treat the token as a one-way signal: firing is informative, silence is not. ## The reading that matters The strongest interpretation is a callback whose source address is **outside** your estate. That says the file was rendered somewhere you do not control, which for a document that lived only on an internal decoy share is close to a statement that the file left. A user agent inconsistent with your standard build strengthens it further. That is the case the token was planted for, and it deserves a different response from a fire whose source is your own egress address at 02:00 on a Tuesday. Second-order details still worth reading: repeated callbacks in a short burst suggest automated processing rather than a person; a callback for a token whose memo places it in a share nobody should have browsed tells you which enumeration path was crossed, because the memo is the only thing that identifies *which* decoy fired. ## Writing the finding honestly The direction of every claim matters here, and it is what an interviewer is listening for. Say "the document was rendered by a client that reached the token service from our egress address at 02:14; the callback does not identify the host or the user, and does not establish that the file was copied." Do not say "an attacker opened our decoy document", because you have not shown an actor, an intent or a copy — and the moment such a claim goes into a report it will be repeated by someone who never read the caveat. ## What a strong answer sounds like "It proves the file was rendered and that the renderer had egress to the token service then. The source address is probably our proxy, and the user agent tells me what opened it — possibly a mail scanner or indexer, not a person. It does not prove copying or intent. The version I would escalate is a callback from an address outside our estate, because a document that only ever lived on an internal decoy share should not be rendering anywhere else."