An authenticated vulnerability scan floods a host's Security channel — how can that erase the intrusion window before the forwarder ships it?

## The two rates that decide whether a record survives A Windows event channel is not a growing file. It is a bounded one with a retention policy, and the common default is to overwrite the oldest records when it fills. A forwarder — the built-in subscription mechanism or an endpoint agent — is a *reader*: it holds a position in the channel, ships batches, and advances. Two rates therefore decide whether any given record ever reaches a collector: the rate at which the host writes, and the rate at which the forwarder drains. While drain keeps up, the channel behaves like a short delay line. When writes outrun it, the file wraps and records are destroyed before anyone has read them. ## Why an authenticated scan is the classic trigger An authenticated vulnerability scan connects to every host with credentials, often several times per host and against several services. Each of those connections produces successful-logon records (Event ID 4624 with logon type 3, meaning a network logon), matching logoff records, and privilege-assignment records for the accounts involved. Multiply that by a scanner working through a subnet and a host that normally emits a few hundred events an hour can emit tens of thousands in a few minutes. The channel wraps. So does a chatty application, a misconfigured audit subcategory, a service crash-looping, or a domain controller during a login storm. ## Why the loss is silent — and why that matters for maliciousness When the forwarder returns to a position that no longer exists, it resumes at the oldest record still present. Some agents emit an indication that their bookmark was overwritten; many do not, and none of them can tell you what the missing records said. Centrally, the result is a stretch of time with fewer records than reality had, and nothing that marks it as incomplete. This is the part candidates get backwards. The absence of records for that host and window is not evidence that nothing happened there. It is evidence that nothing *arrived*. A host that was being used by an intruder at the same minutes the scanner was hammering it can be centrally indistinguishable from a host that was idle — and the destruction was done by your own scanning programme, not by the adversary. The adversary version exists too: anyone who can generate volume on a host, or who simply acts during a published noisy window, gets the same effect for free without touching a single log setting. ## Measure headroom in time, not capacity A channel size in megabytes tells you nothing on its own; the same file holds three weeks on a quiet laptop and eleven minutes on a domain controller. The measurement that means something is **the age of the oldest record still in the channel**. That is your buffer headroom expressed in wall-clock time at the current event rate, and it answers the operational question directly: if the forwarder stopped now, how long before data starts being destroyed? Collect it per host class and alert when it drops below the time you would plausibly take to notice and fix a broken forwarder. Two supporting signals: the forwarder's own queue depth or backlog, and per-host event counts compared against that host's own baseline — a sudden spike is the warning that a burst is in progress, not just an artefact after the fact. ## What you actually do about it - **Raise the channel size where the loss would hurt**: domain controllers, jump hosts, servers holding regulated data. This is cheap and is the single highest-value change. - **Cut the noise at the source.** Turn off audit subcategories that generate volume no detection consumes. Note the direction: this reduces junk so that valuable records survive — it is not the same thing as disabling auditing, which destroys visibility rather than protecting it. - **Prefer an agent that spools to its own on-disk queue.** Once a record is copied into the agent's queue it is decoupled from channel rotation, and a link outage costs latency rather than data. - **Know your scan windows.** Record when authenticated scans run and against which ranges, so that a thin patch of telemetry during triage can be explained rather than argued about. - **State the gap.** If you conclude the channel wrapped during the intrusion window and the forwarder had not drained it, those minutes exist in no copy anywhere. Write that in the report as unobserved time, and let scoping and the re-entry watch treat it as unknown instead of clean.