An auto-close criterion closes any process alert whose parent image is your patch agent - how would an intruder abuse it?
answer
- the predicate is readable from inside the estate
- who is allowed to be the parent?
- a field the adversary can set
- exemptions land on the most powerful identities
- spoofed lineage, matched name, or the real agent
basics
~20 sParent process is adversary-influenceable. Getting code launched by the deployment agent, spoofing the parent process id, or dropping a binary at the allowlisted path all satisfy the criterion, so the one case that mattered is closed unread.
solid answer
~50 sThe criterion is a rule that decides `benign`, and the adversary can read the estate it runs in. Three routes satisfy it. First, abuse the software-distribution path itself: an intruder with the deployment console runs their tool as a package, so the parent genuinely is the patch agent. Second, parent process id spoofing (`T1134.004`), which makes a Windows process-create record report a chosen parent. Third, masquerading (`T1036.005`) if the criterion matches an image path or file name rather than a signed publisher plus full path. The same weakness applies to an exempted service account, or to a scheduled suppression window that is published in the change calendar. Build closure criteria on facts the adversary cannot set, require corroboration from a second source, scope and expire them, sample closures for human review, and alert when a criterion's closure rate or its set of hosts changes.
go deeper
Know that an auto-close criterion is a rule an intruder can read and try to match, and that a parent process name in an event is a claim rather than proof of lineage.
Explain the three concrete routes - abusing the deployment platform, spoofing the parent process id, and masquerading as an allowlisted path - and why a signed publisher plus full path is a stronger key than a file name.
Show how you would operate the criterion: scoped, expiring, corroborated by an independent source, sampled by a human, and monitored for closure-rate and first-seen-host changes.
Own the review model. Decide who is allowed to create a closure criterion, whether they get the same peer review as a detection, and how criteria appear on the coverage report rather than hiding behind a green rule.
## A closure criterion is a detection written backwards A detection rule decides `suspicious` and gets an owner, a test and a review. An auto-close criterion decides `benign`, usually at far higher volume, and in most SOCs was written by whoever was drowning that week. It is also readable: an intruder inside a 30,000-endpoint Windows estate can see which deployment agent runs on every host, which service accounts are exempt from scrutiny, and when the change calendar says maintenance runs. Anything you key a closure on is something they will try to satisfy on purpose. ## Why parent image is a weak key A Windows process-create record - Sysmon Event ID 1, or Security 4688 where audit policy includes the command line - carries the parent image, the child image, the command line, hashes and the user. A criterion of the form *parent image equals the patch-management agent, therefore benign* fails in three distinct ways. **1. The parent really is the agent.** Software-distribution platforms exist to run arbitrary code on every endpoint as SYSTEM. An intruder who reaches the deployment console does not need to defeat your criterion; they inherit it. Every host runs their package, every alert has the blessed parent, and every case closes. This is the strongest version of the attack and no telemetry trick is involved. **2. The reported parent is a lie.** Parent process id spoofing (`T1134.004`) lets a process be created with a chosen parent, so the record names a parent that never launched it. The event is accurate about what the API was told; it is not proof of lineage. **3. The criterion matches a name, not an identity.** If it compares an image *file name*, or a path in a directory that is writable, an intruder places or renames a binary to match (`T1036.005`). A criterion written against the full path of a signed executable, with the signature checked, is much harder - though still not impossible if the agent's own directory is writable. ## The same shape in other predicates - **The exempted service account.** "Alerts from `svc-backup` are noise" is an invitation: an intruder who obtains or impersonates that account gets the exemption, and the account probably has broad rights precisely because it is a service account. - **The suppressed window.** A scheduled suppression is an attack window published in a change ticket. It is worse than an allowlist because it needs no access at all to exploit - only a clock. - **The allowlisted host.** Exempting the build server or the admin jump host exempts the two machines an intruder most wants. In every case the pattern is the same: the exemption is granted to the thing that generates the volume, and the thing that generates the volume is powerful, which is exactly why it is worth compromising. ## What a defensible criterion looks like - **Key on facts the adversary cannot set.** A code signature plus full path beats an image name. An assertion from a second, independent source - the deployment platform's own record that it dispatched this package at this time to this host - beats a single field in the same event the adversary influenced. - **Require corroboration.** Close on the *conjunction* of the alert and an independent fact, not on one field. - **Scope it and give it an expiry.** A criterion that applies to one rule, one account and a named set of hosts, with a review date, cannot silently become an estate-wide exemption. - **Make it visible as coverage loss.** Whoever reads the coverage report should see the criterion, not just the rule. - **Sample.** Have a human read a small random percentage of auto-closures so the criterion has a measured error rate rather than an assumed one. - **Monitor the criterion itself.** Two signals are cheap and strong: the closure rate per criterion, and the *first time* a given host or account starts matching it. An intruder learning to satisfy the predicate shows up as a host that never matched it before and now matches it constantly. ## The interview point The answer that scores is not a list of three tricks. It is the recognition that the closure predicate is part of the attack surface, that it is granted to the most powerful identities in the estate, and that it deserves at least the review, scoping and monitoring you would give the detection it silences.
- How would you detect that someone has learned to satisfy one of your auto-close criteria?Monitor the criterion, not just the rule. Track closure volume per criterion and the first time each host or account starts matching it. An intruder shaping activity to fit shows up as a machine that never matched the predicate before and now matches it repeatedly, or as a closure rate that steps up without a corresponding change in the estate.
- Is corroborating with the deployment platform's own dispatch record actually stronger than trusting the parent image field?Usually yes, because it is a second, independently written source: the agent's server recorded that it sent this package to this host at this time. It is not immune - an intruder who owns the deployment console corrupts both sides - but it defeats parent spoofing and masquerading, and it makes the criterion fail closed when the platform has no matching dispatch.
- The volume comes from one service account and the team wants it exempted. What do you propose instead?Exempt the account only for the specific rule, on a named host set, with an expiry date, and only where a second field confirms the expected behaviour - not a blanket account exemption. Add a detection for that account doing anything outside the exempted shape, so the exemption narrows scrutiny rather than removing it.
saying these in an interview costs you the question
- Treats an allowlisted parent process as a trust boundary
- Assumes a process-create record proves real parentage
- Exempts a service account estate-wide with no expiry
- Never samples auto-closures for human review
- Thinks a maintenance suppression window is secret