An intrusion ran through an RDP gateway whose logs only ever wrote to local disk: why does closure raise a collection requirement, not a detection request?
answer
- the rule was never the problem
- no records means no input
- absence of evidence, not evidence of absence
- the miss sits at collection, one stage earlier
- an empty rule still reads as coverage
basics
~20 sNo rule can match records that never arrived. The miss was at collection, not logic - the gateway's logs stayed on local disk, so the platform's silence was absence of evidence, not evidence of absence. Ship the source first.
solid answer
~50 sThe rule would have had nothing to read. Interactive sessions through the gateway are recorded in its own Windows Security log - 4624 successful logons carrying logon type 10, RemoteInteractive - but that log was only ever written to local disk, so the platform never held one of those records. A detection request here produces a rule that cannot fire and, worse, one that sits in the inventory looking like coverage. So closure raises a collection requirement first: the named source, the host set (every gateway member, not the one you investigated), the events and fields you need, the retention, and the platform owner who must fund and run the ingest. The detection request is a second, dependent obligation written once the records land. The document should also record that the local log had already wrapped, so the earliest activity is unrecoverable.
code
text · 11 linesLog: Security (local file on the gateway host)
EventID: 4624 (an account was successfully logged on)
LogonType: 10 (RemoteInteractive)
TargetUserName: svc-reporting
TargetDomainName: CORP
IpAddress: 10.42.7.19
WorkstationName: WKS-4471
AuthenticationPackageName: Negotiate
TimeCreated: 2026-03-02T02:14:08Z
...
(log had already wrapped; earliest surviving record is 2026-02-27)go deeper
Know that a detection rule reads records from a central platform, and that a source whose logs stay on the host is invisible to it no matter how good the rule is.
Be ready to say which stage failed and why - the records never arrived, so no logic could have matched - and to list what the collection requirement must name: source, host set, events and fields, retention, owner.
Show judgment about scope and sequencing: the smallest event set that makes the behaviour visible, what the local log's rollover cost your timeline, and what you can honestly claim about the period you cannot see.
Frame recurring blind spots as a collection strategy question rather than a per-incident fix, and be able to defend which sources the organisation pays to centralise and which it knowingly leaves dark.
## What actually failed A hunt found valid accounts being used interactively through a remote-desktop gateway. There was never an alert, because there was never a record to alert on: the gateway wrote its events to the local Windows event log and nothing forwarded them anywhere. Everything the investigation knows about those sessions was read off the host by hand, after the fact. That matters enormously for the write-up, because the obvious sentence - `our detection missed it` - is false. Nothing missed it. A detection is logic evaluated over records that have arrived at a platform. If the records never arrive, the quality of the logic is not in question and never was. The gap sits one stage earlier, at collection, and it produces a different artefact with a different owner and a different cost. ## Absence of evidence The most damaging habit this case exposes is reading an empty search result as a clean estate. The platform holding nothing from the gateway supports exactly one conclusion: nothing can be concluded about activity there. It is not evidence that the gateway was quiet, that the detections over it were correctly tuned, or that the rest of the estate is unaffected. The closure should say this in plain words, because the reader outside the SOC will otherwise assume the searches you ran covered the ground. ## What the collection requirement names A requirement that says `forward the gateway logs` will be argued about forever and delivered by nobody. Make it specific enough to cost: - **Source**: the gateway hosts' Security log, plus the gateway service's own session log if it records connection start and end separately. - **Host set**: every member of the gateway pool and any replacement built from the same image, not the single host the incident touched. - **Events and fields**: the smallest set that makes the behaviour visible - successful logons (4624) with **logon type** retained, failures (4625), logoffs (4634/4647), and the account, source address and workstation fields. Volume is where this negotiation is won or lost, and asking for everything is how a requirement gets refused. - **Retention**: driven by how far back an investigator must be able to reconstruct, which is usually much longer than a rule needs. - **Owner**: the platform or identity team that runs the gateway. This is not the SOC's budget, which is precisely why it must be written down rather than assumed. ## What the on-disk log did and did not give you A local Windows event log has a fixed maximum size and overwrites the oldest records when it fills. By the time the hunt reached the host, the log had already wrapped. So the investigation can state the earliest activity it **observed**, but not that this was the first activity - the earlier records simply no longer exist. Writing that limit down is more defensible than implying a start date the evidence cannot carry, and it strengthens the requirement: local rollover is exactly the property that central collection removes, which turns retention from a footnote into part of the ask. Be equally careful about the direction of what the surviving records prove. A 4624 with logon type 10 proves a **credential was accepted** for a remote interactive session from that source address at that time. It does not prove the named employee was at the keyboard, it does not make the session malicious, and it says nothing about what happened inside it. Getting from a logon to activity means process, file and network records on the destination hosts - which is often a second collection requirement, discovered the same way. ## Sequencing the two obligations The detection request is not dropped; it is sequenced. It is written against the behaviour - remote interactive sessions by accounts that have no business using them, at hours and from source ranges that do not fit - and it becomes real work only once the records are landing and someone can see what normal looks like on those fields. Handing a detection engineer a data source plus a described behaviour is a complete handover; handing them a finished query over data that does not exist is not. ## The one-line trap If you take a single sentence from this case, take this one: **a rule deployed over a source nobody collects looks exactly like coverage.** It appears in the inventory, it has an owner, it has never fired - and that is indistinguishable from a rule that has been watching a quiet estate for a year. The collection requirement is what stops a blind spot being converted into a confident one.
- What does a 4624 with logon type 10 on that gateway actually prove?That a credential was accepted for a remote interactive session from that source address at that moment. It does not prove the named person was at the keyboard, it does not make the session malicious, and it says nothing about what was done inside it. Getting from the logon to activity needs process, file and network records on the destination hosts, or the gateway's own session records.
- The local log had already wrapped when you looked. What does that change in the write-up?It bounds the claim. You can state the earliest activity you observed, but not that it was the first - those records no longer exist, and saying so is more defensible than implying a start date the evidence cannot carry. It also sharpens the requirement: local rollover is exactly what central collection removes, so retention becomes part of the ask rather than a footnote.
- Once the gateway logs are ingested, is the detection request automatically satisfiable?Not automatically. Someone still has to establish which field carries the meaning and what normal looks like on it - the logon types in use, the account population, the source ranges, the hours. That authoring and tuning work belongs to whoever maintains the rules. Closure's job is to hand them a real data source and a described behaviour, not a finished query.
saying these in an interview costs you the question
- Reads an empty search result as a clean estate
- Files a detection rule for an uningested source
- Calls this a tuning or triage failure
- Treats a 4624 as proof the named user was present
- Assumes host-local logs are equivalent to central collection
- Scopes the requirement to the one host investigated