Is this thing on?

I will pose this as a question to those with more experience. Hopefully those identified people will be able to set me straight if this is too crazy, or flat out wrong.

I imagine a lot of red team reports close similarly. The blue team did not catch us. Red prevails, and the proof is an empty dashboard because detections never fired.

There may very well be times when it is 100% accurate, but at that point why not just skip the report? I have come to think it is the part of the report that most often gets read, but immediately misunderstood.

What the sentence measures

“Nothing fired” is a claim about sensors, rules, retention, and whether anyone was looking. It is not a claim about the operation.

• If the endpoint agent was not deployed on that subnet, nothing was going to fire no matter what.
• If the rule existed but the log source feeding it had been broken for five weeks, nothing was going to fire.
• If everything worked and an analyst triaged the alert at 2am, decided it was the vulnerability scanner again, and closed it… something did fire, and the report still says nothing.

Those are three completely different organizational problems. The report flattens them into one triumphant sentence about how quiet Red Team was.

The gratification is part of the problem. “I was never here” invites the client to conclude their detection is bad and they NEED us to help them. What actually happened is a specific set of tools and/or techniques met a specific set of sensors on the first Tuesday of the month, and produced a result nobody instrumented well enough to explain.

What the client actually bought

Does anyone buy a red team engagement to find out whether one hot-shot operator can get in? Given unlimited time, scope, and budget an operator can most likely always get in. In todays’ world that is not in dispute.

What they are buying is a measurement of their ability to see it, and the willingness to do so is inspired by the reputation of the team offering the service. What is the actual product being purchased?

So, a report that says “I’m here… where are you?” has skipped the deliverable. It reports the input and omits the output. Worse, there is no way for the client to act on the absence of something, and no way for them to check whether the absence was real.

The version that is actually useful

The difference is in instrumenting the operation, not just the target.

For each technique used you should be able to say what it will produce, whether or not it was produced, and where the evidence is. Something like:

Kerberoasting, day two. Expected: 4769 with RC4 encryption on the domain controller. Confirmed present in Windows event log locally. Not present in Splunk: the DC’s event forwarding subscription was filtering out 4769 entirely. Rule T1558.003 exists and is well written. It never had a chance.

That paragraph is worth more than the entire “we got DA!!!” section. It names a technique, an expected artifact, an actual artifact, a gap, and a specific fix. Somebody can work a ticket from it on Monday morning.

Compare that to “This isn’t where I parked my car…”. One of these tells you your forwarding subscription is misconfigured. The other tells you that you are bad, and you should feel very, very bad. How safe is your job?

Notice too that the useful version is less flattering to the intruders. It says the detection engineering was fine and the plumbing was broken. That is frequently the truth, and reports that never reach that conclusion should be suspicious.

Detect on the invariant, not the artifact

The other half is which detections deserve to exist at all.

A rule keyed to a tool name, a default user agent, or a hardcoded pipe name often only catches exactly one implementation. Afterwards, it stops working the day I change a string and recompile. That is a rule with a shelf life measured in one engagement.

A rule keyed to something the technique cannot avoid doing catches the technique. The service ticket request, the handle to LSASS, the coercion of an authentication attempt, and so on. Changing the tool does not help. Changing the technique means solving a genuinely different problem, which is exactly the cost you want to impose.

Telling a client which of their rules is which can and should be a red team deliverable. If that is not already the case. Well… then, like why not?

My own inspiration

I spent a long time wondering what the defender would actually have seen. I was far too focused on knowing my own tools that I never paid any mind to the mindset of a Blue Team. After realizing I could not answer with any confidence I also realized I had no idea what I may have left behind on each platform.

So I wrote opseclint to answer it:

• Resolve the techniques involved
• Host telemetry each one generates on Linux, Windows, and macOS
• Which Sigma rules would fire.
• Scores 0–100 for detectability.

It is not an evasion tool and I have been fairly blunt about that in its docs. I would really like one of those, though. That’d be sweet. It answers “what would a defender see”. A question you can only act on if you are willing to hear a potentially unwelcome answer.

The governing rule is on the front page of the project, and it is the same sentence this post has been circling:

Absence of a finding is never proof of stealth.

If your last red team report ended with a quiet console and a congratulatory paragraph, that is not a clean bill of health. It is a measurement nobody took.