When do you record an adversary behaviour as undetectable rather than ship a rule that cannot match it?

## The decision, stated precisely You declare a behaviour undetectable when you have walked the candidate records and found that every field a rule could read holds the same values during the behaviour and during legitimate work. That is a statement about the estate and the sensors as they exist today — not about the technique in general, and not about anybody's skill. The worked case: in a legacy Active Directory forest, service accounts that have never been re-keyed hold no AES key, so the KDC issues RC4-encrypted service tickets to everyone who legitimately uses those services. The encryption-type field, which is the field most rules for this behaviour reach for, therefore separates nothing there. If the accounts also cannot be re-keyed — the applications behind them are old, the owners are gone, and nobody will take the outage — you are looking at a genuine dead end on that field. ## Why shipping the rule anyway is the worse option A rule that cannot match does not merely fail to help. It actively closes the question. It appears in the rule repository with the technique's name attached; it is read as "we handle that"; and the next engineer who considers the same gap finds it already addressed. Nothing about it looks broken, because a detection producing no alerts is indistinguishable from a detection watching a quiet estate — the absence of output is not evidence either way. So the failure is silent and permanent, which is exactly the property you cannot afford in a control you may one day have to defend. ## What you produce instead A written verdict, short enough that people read it, containing: - **The behaviour**, described operationally rather than as a label. - **The records examined** and, for each, the field considered and why its values do not separate. This is the part that makes the document trustworthy later — it shows the work rather than asserting a conclusion. - **The change that would create a separating field.** Usually one of three: re-key or replace the accounts so that the anomalous case becomes anomalous again; deploy a sensor to the surface that currently emits nothing; or turn on a configuration that adds the missing field to a record you already collect. Name which, and what it costs. - **An owner and a date.** The change is nearly always somebody else's — identity, platform, endpoint engineering. A gap with no owner is a complaint. - **The expiry condition.** The verdict is true *because* of a stated fact about the estate. When that fact changes, the verdict is void. Write the condition down, and re-run the exercise on a schedule so the document cannot quietly become wrong in either direction. ## The compensating position Declaring something undetectable is not the same as doing nothing, and an interviewer will push on this. You can usually still change the *cost* of the behaviour or the *consequence* of it succeeding even when you cannot see it happening. For static service-account passwords, that means moving what you can to managed accounts whose passwords rotate automatically, giving the ones you cannot move very long random passwords so an offline attack stops being economical, restricting which accounts hold privilege, and watching for what the adversary must do *after* the step you cannot see — because the payoff of a recovered password is its later use, and use has its own records. Detection failure at one step is not detection failure along the whole path. ## Where a deliberately weak rule is still legitimate There is a defensible version of shipping something: a low-value tripwire that catches only the loudest, laziest execution — bulk enumeration in a burst, a well-known tool run on a monitored endpoint — explicitly labelled as covering that case and not the technique. The distinction is not the rule's quality; it is whether its documented scope matches what it can actually catch. A rule honestly described as "catches bulk harvesting from monitored Windows endpoints only" is useful. The same rule named after the technique is the failure described above. ## The organisational half The hard part is rarely the analysis; it is holding the line when a stakeholder wants the gap closed on paper. Two things help. First, always arrive with the cost of the fix, so the conversation becomes a funded decision rather than a refusal — the answer "we cannot see this until service accounts hold AES keys, here is what that migration costs" is actionable in a way that "it is undetectable" is not. Second, make the record of accepted gaps a normal, unembarrassing artefact reviewed on a cadence. A programme that can name what it cannot see is far more credible than one whose repository claims everything is covered — and it is the only version that survives someone testing the claim.