Detonator: open-source pipeline enables reproducible EDR evasion testing without a cloud console

A testing pipeline that skips the cloud console

A dev.to post by the author writing as excalibra tackles a familiar constraint for red team operators: a CrowdStrike-protected endpoint is available, the sensor is online and enforcing, but there is no access to the cloud-based Falcon console. Many treat that as a dead end. The post's central claim is the opposite — the console only tells you whether a sample was killed, not where the attack chain broke, and it is that second piece of information a tester actually needs. The author pairs the argument with a working pipeline built on Detonator, an open-source framework for automated EDR testing.

The six stages worth examining

According to the post, useful debugging means asking a specific question at each phase of execution:

• File dropping: does the alert fire on writing to disk, or only during execution?
• Process startup: are the parent process chain or startup parameters anomalous?
• Memory operations: which call fails — VirtualAlloc, VirtualProtect or WriteProcessMemory?
• Execution flow transfer: is the trigger APC injection, thread hijacking, a callback or SetWindowsHookEx?
• Command and control: is outbound traffic flagged via DNS or HTTPS JA3 fingerprinting?
• Persistence: is a Run key write blocked or a scheduled task intercepted?

None of those answers, the author notes, come from console logs. They come from deliberately designed experiments.

One variable, one clean snapshot

The prescribed methodology is deliberately narrow: change exactly one parameter per run — the encryption algorithm, the injection technique or the C2 protocol — while holding everything else constant. When a single alteration flips the detection outcome, the trigger has been isolated and the fix can target one specific call instead of forcing a rewrite of the whole loader.

That only works if runs are reproducible. EDR products keep state, the post explains: cached detection results, behavioural models that evolve locally, and continuous scoring of processes over time. Firing a second sample at a machine that has already seen the first may produce a detection that reflects sensitisation rather than the new sample's own behaviour. The workaround is a clean snapshot for every test, so each run starts from the same baseline with only one variable in motion.

What Detonator does

Detonator automates that loop. A sample is submitted to a controller, which dispatches it to a virtual machine running the target EDR, executes it, collects the detection outcome and returns a report. The framework supports Microsoft Defender, Defender for Endpoint, Elastic Defend, CrowdStrike, Fibratus and RedEdrd, among others.

Setup involves installing the controller on a Linux or Windows machine using standard Python tooling, preparing a Windows test VM with the Falcon sensor and a clean snapshot, installing the in-guest agent via a provided PowerShell script, and describing each environment in a YAML profile. Samples are then submitted against a profile from the command line, and the output reports the result together with the specific rule that fired — observable locally, the author argues, because the sensor killing the sample is itself visible on the endpoint. An AutoIt mode simulates user interaction such as file-manager navigation, paste operations and keypresses, so realistic chains, including ClickFix-style attacks, can be evaluated.

A commercial footnote

The post is not purely educational. Its author also sells authorised EDR endpoint tokens for CrowdStrike, SentinelOne, Trend Micro and other platforms, aimed at building exactly these lab environments, and the article points back to a longer version on the author's own site.

Why it matters

The core argument — that reproducibility, not log access, is the real bottleneck in EDR testing — applies to defenders as much as attackers. Purple teams validating sensor coverage face the same stale-state contamination that snapshot-per-run testing eliminates, and an open-source harness that automates clean-room runs across several EDRs lowers the cost of applying that discipline. At the same time, the material is dual-use and sits close to operational guidance, and the commercial tie-in means readers should weigh the framing accordingly.