Your CDN-fronted C2 rule has been rewritten three times this month — what must its replacement prove?

## Read the ledger first Three rewrites in a month is data, not an annoyance. It says every field the rule has matched on so far — the fronted hostname, the edge address, the certificate serial, the TLS client fingerprint — is an artefact of *this deployment* of the technique rather than a property of the technique. Each rewrite bought a few days of coverage and cost real time from a team that has one analyst and no dedicated detection engineer. The right response is not a fourth rewrite; it is to change what the rule is written against, and to set a bar the replacement must clear before it takes the slot. ## Bar one: the clause must be demonstrated, not asserted An invariant is a property the operator cannot drop while still doing the thing they are doing. Candidates for the CDN-fronted case usually live one layer away from the network artefacts, because the network artefacts are exactly what is cheap for them to churn: - the initiating **process** is not a browser, an updater or any sanctioned client, yet it is holding outbound TLS sessions to an internet edge; - the destination was contacted with **no preceding name resolution** from that host, or by an account that never runs interactive web traffic; - a **service account** with no interactive logon history is originating proxy traffic at all. Every one of these is a hypothesis until it is tested. The test that separates an invariant from an artefact you simply have not watched change yet is **executing the behaviour with the fixed artefacts deliberately swapped**. Stand up a new fronted hostname, present a different certificate, use a different TLS library so the client fingerprint moves, rebuild the payload so the hash moves — then run the technique and watch whether the candidate clause fires. That is the only evidence available to you, and it is a genuinely different exercise from replaying the record you captured during the last case: that record still contains the old hostname and the old fingerprint, so a replay tells you the rule matches history, not that it matches the technique. This matters more here than in most detection work, because a detection's silence is uninformative. A rule that has never fired might be guarding a quiet estate or might have been dead since the day the hostname rotated, and its own output cannot tell the two apart. You cannot compute a miss rate from an absence. The only way to know the rule works is to make the behaviour happen. ## The trap: promoting a slower artefact The most common failure at this point is to notice that one field changed less often than the others last quarter and to declare it the invariant. A TLS client fingerprint such as a JA3 value is still an artefact — it is a hash of ClientHello fields, and it moves when the operator changes TLS library, version or configuration. "It has held for six weeks" is evidence about your observation window, not about the field's nature. The question to ask about any candidate clause is structural: *if this field changed, would the operator still have their capability?* If the answer is yes, you are looking at an artefact and you will be back here next month. ## Bar two: know the benign population before you ship A behavioural clause that survives artefact churn will also match legitimate software, and on a one-analyst team an untuned behavioural rule is worse than no rule, because it consumes the only triage capacity you have. So the replacement must arrive with an answer to "what legitimate things satisfy this?" — the backup agent, the monitoring collector, the software-distribution client, the security tool's own updater. Enumerate them from your own telemetry before rollout, exclude them on stable attributes rather than on the same volatile artefacts you are trying to escape, and record each exclusion so a later reader knows what the rule stopped covering. These hits are **benign true positives**: the clause matched what it says it matches and the cause is authorised. Treating them as false positives is how people weaken the behavioural condition itself and end up back with something artefact-shaped. ## What ships, and what happens to the old rule The outcome is a portfolio trade rather than an escalation. The behavioural rule takes the alerting slot. The artefact rule does not need a fourth rewrite; what remains useful from it — the small set of hostnames and addresses tied to this specific activity — folds into a narrow match list with an expiry date and a named owner, where it costs almost nothing and closes the occasional case fast. Then keep measuring the thing that started this: rewrites per rule per quarter. If the replacement is still being rewritten in three months, the clause was not an invariant, and the honest conclusion may be that nothing you currently collect separates this behaviour from normal work.