Advanced·500 points·2 solves
Detection Engineering: Building a Rule That Survives Contact
Work out why a rule that describes the right technique still missed most of the activity it was written for, rebuild it on a property the operator could not change, and then measure the rebuilt rule over four days of real telemetry — because the rule that finds everything and the rule that can actually ship are usually not the same rule.
Almost every detection that fails in production fails the same way. Someone investigates an incident, writes down what they saw, and turns those observations into conditions. The conditions are all true of that incident, so the rule is tested, it fires, and it ships. What nobody asks is which of those observations the operator chose and could just as easily have chosen differently. Anything they picked — a filename, a directory, a parent process, a user agent, the order of the arguments — is a property of one afternoon, not of the technique. A rule built on those tests whether the next operator makes the same arbitrary choices. Usually they do not. So the first question about any rule is: which field does it key on, and could the person on the other end have changed it without changing what they achieved? When the answer is yes, the fix is to look for something in the same telemetry that describes the same activity and is expensive or impossible to vary. Such a property usually exists, and it is usually already being collected — the agent records more about a process than the path it was launched from, and some of what it records comes from inside the file rather than from where the file happens to be sitting. Finding that property is the first half and it is the easy half. It will match far more than the intrusion, because the legitimate estate uses the same tools the operator does — that is why the operator chose them. Narrowing it down is where rules are actually made, and it is where the second mistake lives. An exclusion is an instruction to ignore something, so it is also an instruction anyone who learns of it can follow. Exclude on a property the operator controls and you have handed them a way past your rule; worse, you may already have deleted part of the incident you were hunting, and unless you counted what your exclusion removed you will never know. Exclusions belong on infrastructure the operator does not own. Evidence is in /var/log/soc. Read detection-brief.md first, then rule-standard.md, which is the house standard the review board will hold your rule to.
Your tasks
1
Read the rule that missed, and name the assumption in it
Open existing-rules.yml and find the rule the brief refers to. It has two conditions. One describes the technique and is sound. The other describes where the executable happened to be, on the one occasion someone looked. Identify which field carries that second condition, and satisfy yourself from the telemetry that its value differs across the activity — that is the whole reason the rule reported one machine.
2
Find the property that did not move
rule-standard.md lists every field the EDR agent provides and says plainly what each one describes. Exactly one of them is derived from the contents of the executable rather than from its location, which means copying the file somewhere else under another name does not change it. Identify that field, then use it to find the full set of executions the original rule was blind to.
3
Measure the naive rule honestly
Count every event in edr-process.json carrying that value, and then account for the difference between that number and the number of executions that belong to the intrusion. Most of the gap is a scheduled job that uses the same binary for something entirely unrelated and never downloads anything. Add the condition from the original rule that WAS sound and count again. You are now much closer, and the remainder is the interesting part.
4
Identify the legitimate activity you cannot simply exclude
The events still matching that are not the intrusion come from an internal tool doing genuinely the same thing for a genuinely good reason. Identify the parent process behind them. Then — before excluding it — apply the standard: count what that exclusion would remove and check none of it is the activity you are hunting. It is not a rhetorical exercise. Record how many true detections that exclusion costs, and which machine loses one.
5
Key the exclusion on something the operator does not own
A parent process is chosen by whoever runs the command. Look instead at where each download is going: the internal tool is fetching from infrastructure the company runs, and the operator has to fetch from infrastructure they run. That distinction is not available to the operator to fake without giving up their payload. Record the destination that identifies the malicious set, and confirm the finished rule returns every execution of the intrusion and nothing else.
6
Classify it
Name the ATT&CK technique for running a signed system utility under a different filename to avoid detections that key on its name — the sub-technique, not the parent. It is the one that should have been in the original rule's notes as a known evasion, and its absence is why the rule was accepted with the weak condition in it.
Answer the questions
Start the lab, investigate the evidence in the terminal, and answer the questions here.